A storage server is a special-purpose processing system used to store and retrieve data on behalf of one or more client processing systems (“clients”). A storage server can be used for many different purposes, such as, to provide multiple users with access to shared data or to back up mission critical data.
A file server is an example of a storage server. A file server operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical storage based disks or tapes. The mass storage devices may be organized into one or more volumes of Redundant Array of Inexpensive Disks (RAID). Another example of a storage server is a device which provides clients with block-level access to stored data, rather than file-level access, or a device which provides clients with both file-level access and block-level access.
In conventional file servers, data is stored in logical containers called “volumes” and “aggregates”. An aggregate is a logical container for a pool of block storage, from which one or more RAID groups can be created. A volume is a set of stored data associated with a collection of mass storage devices, such as disks, which obtains its storage from an aggregate, and which is managed as a single administrative unit, i.e., as a single file system.
In conventional file servers there is a fixed, one-to-one relationship between a volume and an aggregate, i.e., each volume is exactly coextensive with one aggregate. Consequently, there is a fixed relationship between each volume and the disks that are associated with it. This fixed relationship means that each volume has exclusive control over the disks that are associated with the volume. Only the volume associated with the disk can read and/or write to the disk. Unused space within the disks associated with the volume cannot be used by another volume. Thus, even if a volume is only using a fraction of the space on its associated disks, the unused space is reserved for the exclusive use of the volume.
To overcome these limitations and other limitations of traditional volumes, a technology called FlexVol™ has been developed by Network Appliance, Inc. of Sunnyvale, Calif., and is available in Filers made by Network Appliance as a feature of the Data ONTAP™ storage operating system. FlexVoI™ technology provides a kind of volume called a “flexible volume” or “virtual volume”. A virtual volume is analogous to a traditional volume in that it is managed as a file system, but unlike a traditional volume, it is treated separately from the underlying physical storage that contains the associated data. A “virtual volume” is, therefore, a set of stored data associated with a collection of mass storage devices, such as disks, which obtains its storage from an aggregate, and which is managed as a single administrative unit, i.e., as a single file system, but which is flexibly associated with the underlying physical storage.
FlexVoI™ technology allows the boundaries between aggregates and virtual volumes to be flexible, such that there does not have to be a one-to-one relationship between a virtual volume and an aggregate. An aggregate can contain multiple virtual volumes. Hence, virtual volumes can be very flexibly associated with the underlying physical storage block characteristics. Further, to help reduce the amount of wasted storage space, any free data block in an aggregate can be used by any virtual volume in the aggregate. A virtual volume can be grown or shrunk in size. Furthermore, blocks can be committed to virtual volumes on the fly from available storage.
While the advantages of FlexVoI™ technology are apparent, it also creates certain challenges, particularly with regard to controlling administrative access to virtual volumes. A storage server on a network typically is managed by one or more network administrators, who may be responsible for configuring, provisioning and monitoring the storage server, scheduling backups, troubleshooting problems with the storage servers, performing software upgrades, etc. These administrative tasks can be accomplished from a management console. The management console is a separate computer system that runs a storage management software application and communicates with the storage server either directly or through a network.
There may be multiple network administrators who are authorized to perform administrative operations on a given volume, from various different administrative consoles. To avoid data inconsistencies and other errors from occurring, it is necessary to ensure that potentially conflicting administrative operations cannot be performed simultaneously on a given volume; i.e., it is necessary to serialize potentially conflicting administrative operations. Examples of administrative operations include: creating a volume, destroying a volume, placing a volume online, taking a volume off-line, renaming a volume, etc. For example, it is undesirable to allow one administrator to destroy a volume while the volume is being read by another administrator.
To address this issue, a feature known as RAID Lock has been employed to enforce serialization on administrative operations in file servers that use traditional volumes. RAID Lock is a simple spin lock implemented within the aggregate layer of a storage server's operating system. RAID Lock works well in a traditional system where there must be a one-to-one relationship between a volume and an aggregate. However, RAID Lock is not effective when used with virtual volumes, since there no longer must be a one-to-one relationship between aggregates and volumes.
More specifically, if RAID Lock were used with virtual volumes, then all administrative operations across all volumes in the same aggregate would have to be serialized. Consider an example where an administrator wishes to take offline a particular virtual volume in a particular aggregate. To do this, the administrator would have to take the aggregate's RAID Lock. For however long the aggregate's RAID Lock is held, any other administrative operation on any other virtual volume in that aggregate (and there could be hundreds) would be blocked. This result is highly undesirable from a performance standpoint, since all of these other operations on all of these other co-resident virtual volumes may be completely independent and otherwise semantically capable of being done in parallel.